The statements in this section merely provide background information related to the present disclosure and may not constitute prior art.
For a USB device to be able to communicate with an operating system of a target device, for example a target computer, the target computer needs to know which driver(s) to use to support the device. For example, if the target computer is running the Microsoft Windows® operating system, and the USB device is directly supported by the Windows® operating system, then the USB device will be auto-mapped, for example by using a driver like “HID” (Human Interface Device) or “Mass Storage” to a driver present in the Windows® operating system. This typically happens when any type of supported USB device is first plugged into a USB port of a computer running the Windows® operating system. The Windows® operating system essentially looks at the class of the supported USB device that it is communicating with and automatically “enumerates” the supported USB device to the appropriate device drivers that are included in the Windows® operating system. By “enumerates” it is meant that the required device drivers are automatically mapped to the USB device by the Windows® operating system.
When using an unsupported USB device to attempt to communicate with a computer running the Windows® operating system, a challenge arises because the Windows® operating system does not know what driver to map to the device. Furthermore, it may not have the necessary driver to support the USB device. This necessitates the user having to supply an “.inf” or driver file(s) to the Windows® operating system which tells it (based on the USB vendor/product ID) the specific driver that the enumerating USB device maps to. Of course, the .inf or driver file(s) could be supplied via an Internet connection to the computer running the Windows® operating system, but the requirement for communicating the .inf or driver file(s) over an Internet connection can itself present challenges. For example, entities often have restricted LAN/WAN access which may prevent the device from accessing the files from the Internet. So updating a driver via the Internet is not often practical in real world applications.
Another option would be to simply include the needed driver install file on a portable media device (e.g., USB flash drive) that is plugged in to a USB port of the target computer. However, this necessitates that the portable media device be physically plugged into every computer that the USB device might need to communicate with. In some applications, and particularly KVM (Keyboard/Video/Mouse) applications, this can be impractical, as the USB device may need to communicate with a plurality of different target computers. Moreover, physical access to the target computer(s) may also be restricted, such as if the target computer is in a data center room with controlled access.
So the challenge remains how to easily and efficiently enable a non-supported USB device to communicate with the operating system of a target computer, and without requiring use of a wide area network such as the Internet, and without the need to physically couple a separate media device with the device install file on it to the USB port of each and every target computer that the USB device needs to communicate with.